Method and system for testing a universal serial bus within a computing device

ABSTRACT

The present invention generally relates to the field of testing computing devices. More specifically, the present invention relates to a system and method for testing a universal serial bus (“USB”) within a computing device. In an exemplary embodiment, the system includes a test device and a test control module. The test device is connected to a USB port on the computing device. The test control module resides on the computing device and interacts with the test device to test the USB port. Once connected, the test device is used to monitor signals on the USB port exchanged between the test device and the USB port. Examples of signals that are monitored are the voltage levels, frame timing, and USB bus signals and power voltages. The test device then communicates the monitored information to the test control module for analysis. The test control module is further capable of causing a second set of tests to be performed including a full-speed device detect test, a bulk transfer test, an isochronous transfer test, an interrupt transfer test, and a low-speed device detect test. The results of these tests are then communicated to the user.

CROSS-REFERENCES TO RELATED APPLICATION(S)

The present application claims the benefit of priority under 35 U.S.C. §119 from the provisional patent application, U.S. patent applicationSer. No. 60/187,317, filed on Mar. 6, 2000, which is hereby incorporatedby reference as if set forth in full in this document.

BACKGROUND OF THE INVENTION

Universal serial buses (USBs) can be used to connect a wide variety ofperipheral devices, such as mice, modems, keyboards, and printers, to anelectronic device, such as a personal computer. The use of universalserial buses has become quite widespread. For example, most personalcomputers now offer a universal serial bus port as one of the standardoutput options. Possibly, the universal serial bus port could one daycompletely replace serial and parallel ports.

A USB environment generally includes three parts, namely, a USB hostcontroller which is integrated as part of a computing device, a USBdevice, and a USB cable which is used to connect the USB device to theUSB host controller. More specifically, the USB host controller includesa USB port which receives the USB cable thereby allowing the USB deviceto communicate with the USB host controller.

Typically, testing of USB centers around the information exchangedbetween the USB host controller and the USB device. Usually, testing ofthe communication between the USB device and the USB host controller isdone only during the design phase of the computing device containing theUSB host controller. For example, USB protocol analyzers, such as a CATCprotocol analyzer or a Quality Logic protocol analyzer, are designed foruse by designers to verify a USB design. The designers use the protocolanalyzers to primarily test the operation of a USB device and to displaythe data that is exchanged between the USB host controller and the USBdevice. Some protocol analyzers can also collect a multitude ofinformation, such as voltage levels, speed of operation, and timingsignals, from the computing device. Once the information is collected,it is up to the designer to decipher the accuracy and meaning of suchinformation.

In a typical test environment, the computing device, for example, acomputer which contains a USB host controller to be tested is connectedto an external USB device, such as a printer, via a USB port and a USBcable. The protocol analyzers is then inserted in between the USB hostcontroller and the USB device by using a first USB cable to connect theUSB host controller to the protocol analyzer and using a second USBcable to connect the protocol analyzer to the USB device. Basically,these analyzers detect and then capture signals that are sent by the USBhost controller via the USB port and USB cable to the USB device, suchas a printer. The results of these signals are then interpreted and usedby the designer to make any necessary alterations to the design of theUSB device and/or USB host controller.

Protocol analyzers when used as a testing device have a number ofshortcomings. For example, the information generated by protocolanalyzers requires considerable skills to decipher. Moreover, protocolanalyzers are generally very cumbersome and bulky. Additionally, theyare not economical or feasible for the general public or individualconsumer to own. Thus, a person outside of the design environment willgenerally not have access to a testing device to determine if a USB hostcontroller, a USB cable, and/or a USB port are working properly.Protocol analyzers are not designed for users to test if these featuresare not working; but rather, for a designer to use in the development ofa USB-supported device.

Furthermore, a typical scenario in which a user of a computing deviceneeds to troubleshoot the USB is when a USB device is plugged in and yetnot detected by the computing device. The problem may lie with the USBdevice, the USB cable, the USB port or the USB host controller. Underthis type of configuration, troubleshooting of problems usually focuseson excluding failure sources without dismantling all the components ofthe USB environment.

Hence, it would be desirable to provide a testing device which iscapable of testing a USB host controller and USB port within a computingdevice in a swift and efficient manner.

SUMMARY OF THE INVENTION

The present invention generally relates to the field of testingcomputing devices. More specifically, the present invention relates to asystem and method for testing a universal serial bus (“USB”) within acomputing device.

A system and method for testing a computing device is provided by virtueof the present invention. In an exemplary embodiment, the systemincludes a test device and a test control module. The test device isconnected to a USB port on the computing device. The test control moduleresides on the computing device and interacts with the test device totest the USB port. Once connected, the test device is used to monitorsignals on the USB port exchanged between the test device and the USBport. Examples of signals that are monitored are the voltage levels,frame timing, and data signals and their voltages. The test device thencommunicates the monitored information to the test control module foranalysis. The test control module is further capable of causing a secondset of tests to be performed including a bulk transfer test, anisochronous transfer test, an interrupt transfer test, a full-speeddevice detect test and a low-speed device detect test. The results ofthese tests are then communicated to the user.

In another exemplary embodiment, the test device includes a USB portwhich is capable of receiving a USB cable. One end of the USB cable isconnected to the test device while the other end of the USB cable isconnected to the USB port. Using this arrangement, the USB cable whichis used to connect the test device and the USB port can be tested.

Accordingly, in one embodiment, the present invention provides a systemfor testing a universal serial bus port of a computing device,including: a test control module residing on the computing device, and atest device coupled to the universal serial bus port, wherein the testcontrol module communicates with the test device in order to perform aseries of tests on the universal serial bus host controller, theuniversal serial bus port and the universal serial bus cable.

Furthermore, in another embodiment, the present invention provides amethod for testing a universal serial bus port of a computing deviceusing a test device and a test control module, comprising: connectingsaid test device to said universal serial bus port using a universalserial bus cable, initializing said test device, causing said testdevice to provide information for a series of tests in response toinstructions received from said test control module, communicating saidinformation to said test control module, and causing said test controlmodule to analyze said information to determine whether said universalserial bus port and cable are functioning properly.

A further understanding of the nature and advantages of the presentinvention herein may be realized by reference to the remaining portionsof the specification and the attached drawings. Reference to theremaining portions of the specification, including the drawings andclaims, will realize other features and advantages of the presentinvention. Further features and advantages of the present invention, aswell as the structure and operation of various embodiments of thepresent invention, are described in detail below with respect to theaccompanying drawings. In the drawings, like reference numbers indicateidentical or functionally similar elements.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a simplified block diagram illustrating an exemplaryembodiment of the present invention; and

FIG. 2 is a flow diagram illustrating the testing process in accordancewith one embodiment of the present invention.

DESCRIPTION OF THE SPECIFIC EMBODIMENTS

The present invention will now be described. FIG. 1 shows a universalserial bus (USB) testing system 10 that is used to test a USB port 16 ofa computing device, such as a computer 14. It should be understood thattesting the USB port 16 is meant to include testing a USB hostcontroller 24. The USB host controller 24 is generally integrated aspart of the computing device and communicates with the outside world viathe USB port 16. In this exemplary embodiment, as shown in FIG. 1, thetest system 10 includes a test device 12 and a test control module 18.

The test control module 18 is, preferably, implemented using software.Generally, the test control module 18 resides on the computer 14. Thetest control module 18 controls the testing process and interacts withthe test device 12 and the USB host controller 24 to determine whetherthe USB port 16 and the USB host controller 24 are functioning properly.The testing process and the interaction between the test device 12 andthe test control module 18 will be described in further detail below.

The test device 12 further includes a device controller 20 and a testresponse module 22. The device controller 20 is responsible forperforming standardized USB functions including, for example, handlingthe exchange of USB signals between the USB port 16 and the test device12 and monitoring the accuracy of the USB signals. In one embodiment,the test device 12 is implemented using two discrete IC chips, namely, aUSB controller which handles the exchange of USB signals and acts as thedevice controller 20 and a microcontroller which acts as the testresponse module 22. In an alternative embodiment, the two discrete ICchips may be combined into a single chip which is capable performing thesame functions. It should be understood that a person with ordinaryskill in the art will know of other ways to implement the functionalityof the test device 12 using one or more IC chips.

Furthermore, the test device 12 optionally includes a number of externalsignals (not shown), such as LEDs, which are used to indicate theresults of the test. A person of ordinary skill in the art will know ofways and methods to implement such external signals.

In another exemplary embodiment, the test device 12 includes a portwhich is capable of receiving a USB cable. The purpose of having thisport on the test device 12 will be explained below.

In an exemplary embodiment, the test response module 22 is implementedusing software or firmware. As will be described in further detail belowin connection with the testing process, the test response module 22responds to the test control module 18 and provides certain requestedinformation from the device controller 20 to the test control module 18.Based on the requested information, the test control module 18determines whether the USB port 16 is functioning properly.

The computer 14 includes the USB port 16. However, it should beunderstood that the computer 14 can contain any number of ports. In aspecific embodiment, each port has four USB standard wires including: adifferential data signal pair marked D+ and D−, and a +5 volt powerwire, and a ground wire.

A single test device 12 can be used to test one USB port 16 of thecomputer 14 at a time, or multiple test devices can be placed inmultiple or all USB ports at the same time. Additionally, ports of a USBhub can be tested by attaching the hub to the computer 14 and attachingthe test device 12 to the ports of the hub. As shown in FIG. 1, duringoperation, the test device 12 is directly connected to the computer 14through the USB port 16.

During operation, the test control module 18 residing on the computer 14initiates the testing process by sending signals to the test device 12connected to the USB port 16. The test device 12 via the test responsemodule 22 responds to the test control module 18. More specifically, thetest response module 22 collects certain diagnostic information from thedevice controller 20 and forwards such information back to the testcontrol module 18. The test control module 18 then accordingly analyzesthe received information and determines whether the USB port 16 isfunctioning properly. Preferably, the results of the determination arerelayed to the test response module 22 which, in turn, activates theappropriate external signals. The testing process and the interactionbetween the test control module 18 and the test response module 22 willbe more fully described below.

FIG. 2 is a flow diagram illustrating the testing process in accordancewith one embodiment of the present invention. According to thisexemplary embodiment, at S1, a user connects the test device 12 to theUSB port 16 of the computer 14.

Once connected, at S2, the test device 12 performs a self-test on thevoltage level(s) of the USB port 16 to ensure that the USB port 16 isoperational. More specifically, the test response module 22 checks thevoltage level(s) of the USB port 16 to determine if they are within USBspecification. For example, the test response module 22 can check if thepower wire voltage level of the USB port 16 is +5 volts, which is theproper voltage according to current USB specification. Also, a minimum,maximum, or range of values can be checked. For example, the rangebetween a +4.4 volt minimum and a +5.25 volt maximum can be deemedproper. The specific acceptable values are defined by the USBspecification.

The test response module 22 then conveys the results of the check to theuser. For example, once the voltage level(s) is determined to beadequate, the appropriate external signal on the test device 12 iscaused to illuminate to indicate that the voltage level(s) of the USBport 16 is adequate.

Alternatively, voltage from the USB port 16 can be used directly toilluminate a signal light on the test device 12. If the signal lightfails to illuminate, then it is an indication that the voltage levelprovided by the USB port 16 is not acceptable.

It should be understood that while the voltage level test is describedherein as self-initiated by the test response module 22 after the testdevice 12 is plugged into the USB port 16, this test can bealternatively initiated by the test control module 18.

At S3, the user via the test control module 18 starts a series of teststo check the USB port 16. At S4, if needed, the test control module 18enables the test device 12 and the USB host controller 24 and the USBport 16. The USB host controller 24 and the USB port 16 may need to beenabled because not all operating systems include support for the USBprotocol. Any operating system that does not support the USB protocolrequires the use of special software, which is included as part of thetest control module 18, to enable the USB host controller 24. An examplewhere the test control module 18 does not need to enable the USB hostcontroller 24 and the USB port 16 is when an operating system alreadycontains the proper bus drivers which support the USB protocol, such asin a Windows 98 environment. An example of an operating system where aUSB protocol may not be supported is DOS. In enabling the USB hostcontroller 24 and the USB port 16, the test control module 18 generallyinstalls certain drivers to enable the USB host controller 24 and theUSB port 16.

At S5, the USB host controller 24 detects whether the test device 12 ispresent for communication. The way the USB host controller 24accomplishes this task is commonly understood under the USBspecification. If the test device 12 is not detected by the USB hostcontroller 24, the USB host controller 24 accordingly informs the testcontrol module 18 which, in turn, informs the user that the test device12 is absent. Testing of the USB host controller 24 and the USB port 16is then halted.

When the test device 12 is detected by the USB host controller 24, theUSB host controller 24 informs the test control module 18 of thepresence of the test device 12. The test control module 18 then performsa full-speed device detect test to verify whether the test device 12 isa full-speed device in accordance with the USB specification. Ways tocontact the full-speed device detect test are commonly understood underthe USB specification.

At S6, the test device 12 is configured according to the USB protocol.This configuration step is performed because the USB protocol allows aUSB-enabled device to assume one of many configurations. In configuringthe test device 12, the operating system or test control module 18(hereinafter “host”) sends a query packet to the test device 12 askingwhat configurations are available on the test device 12. If the testcontrol module 18 is unable to receive the configuration informationfrom the test device 12, then the test control module 15 informs theuser and accordingly halts the testing process.

Otherwise, in response to the query packet, the test device 12 sends aresponse packet containing the available configurations to the host. Theavailable configurations are then displayed to the user for selection ifnecessary. The host then selects the desired configuration. Uponselecting a particular configuration, the appropriate device drivers foruse with the selected configuration are then loaded by the host. Thehost also informs the test device 12 which configuration has beenselected. The test device 12 is then accordingly configured. The user isthen signaled when the configuration is complete. In a specificembodiment, a configuration complete light on the test device 12 can belit or can change to a different color from the existing color.Additionally, a ringing sound or message can be used.

After configuration, at S7, the USB frame timing is monitored. Morespecifically, the USB frame timing between the test device 12 and thetest control module 18 is monitored by the test response module 22. TheUSB frame timing is a measure of the amount of time between twosuccessive frame starts. For example, a standard may be the USBspecification of 1.000 milliseconds per frame, with an accuracy ofbetter than ±500 nanoseconds. The test device 12 measures the length ofa frame by monitoring the amount of time between two successive framestarts. The average, minimum, and maximum frame times are also measured.These measurements are made by the test response module 22. The frametiming measurements are then stored in the test device 12, morespecifically, in the test response module 22. For example, it can bemeasured that frame timings are 0.996, 1.004 and 1.000 in successiveframes. Thus, the minimum value stored would be 0.996, the maximum1.004, and the average 1.000.

At S8, the test device 12 also monitors the quality of the bus signaland power voltages. More specifically, the monitoring is performed bythe test response module 22. Information on the quality of the bussignal and power voltages is monitored to ensure that the datatransmitted over the USB port 16 are correctly represented. For example,bus signaling for a high signal may need to exceed a certain thresholdvoltage level and a low signal may need to stay below another thresholdvoltage level. Also, the power wire may need to provide at least aspecific level of voltage. The specific voltage levels may differ, basedon the version of the USB specification. For USB v.1.1, the nominalvoltage levels are +3.3V for a high and 0V for a low on the USB D+ andD− differential data wires, and +5V for the power wire. The USB v.1.1specification also allows for a variance from these levels to a minimumof +2.0V and a maximum of +3.6V for a high and a minimum of 0V and amaximum of +0.8V for a low on the D+ and D− signal lines, and a minimumof +4.4V and a maximum of +5.25V on the power wire. In addition, thedifferential between the D+ and D− lines must be at most 200 mV. Thedifferential voltage is calculated by subtracting the measured D− fromD+0 and comparing the results thus calculated for when the bus issignaling a bus logic 0 or a bus logic 1. Note that USB uses NRZIencoding for data transmission, thus a logic 0 and logic 1 on the bus donot necessarily mean that the data bit that is transmitted is a 0 or 1respectively.

Information relating to the average, minimum, and maximum levels of thebus signal and power voltages are then stored in the test device 12.Preferably, three values for the power voltages and three values for thebus signal are stored. These values will then be analyzed by the testcontrol module 18 as will be described below.

At S9, the test control module 18 communicates with the test responsemodule 22 to request the test results and statistics from the priorsteps. In this step, the test control module 18 reads the test resultsfrom a results buffer of the test response module 22. In a typicalimplementation, a USB “pipe” which can be read using standard USBcommands is used, and the result of the read is a data structure thatcontains the test results.

At S10, the test response module 22 receives the request and thenresponds with the requested test results and statistics in a binarystructure. The response structure containing the test results andmeasured statistics is then received by the test control module 18 foranalysis. Failure conditions are detected if a measured value returnedin the response structure is out of acceptable tolerances. Theacceptable tolerances are set forth under the USB specification. Forexample, a frame timing may be too slow or too fast, or a certainvoltage level may be too high or too low. The user, via the test controlmodule 18, may further adjust the acceptable tolerances to be morestringent than those set by the USB specification.

At S11, the test control module 18 causes a bulk transfer test to beperformed. The purpose of the bulk transfer test is to verify that datais sent and received without errors. Bulk transfers are checked forerrors. Any transmission errors or errors in the content of data packetsthat are sent are then detected. An example of a bulk transfer istransfer of data from a floppy drive to a USB-enabled device wherepremium is placed on the accuracy of the transferred data and timing ofthe transfer is of less importance.

More specifically, the bulk transfer test is performed by the testcontrol module 18 by sending data to the test device 12. This data isinitially placed in a buffer by the test device 12. The buffered data isthen read by the test control module 18 using bulk data transfers fromthe test device 12 to the test control module 18. After the test controlmodule 18 receives the data from the test device 12, the test controlmodule 18 compares the received data to the data that it previouslysent. If the two sets of data match, the error-corrected USB transferwas successful. This test may be repeated with various data, withvarying lengths of different sequences of numbers that are selectedspecifically to create worst-case electric noise and transfer scenariosfor the USB host controller 24 and the USB cable. The USB specificationv.1.1 defines four data payload sizes that can be used for bulktransfers: 8, 16, 32 and 64 bytes. Future USB specifications may addother bulk transfer sizes.

Bulk data transfers are error-checked by the test device 12 and the USBhost controller 24 in cooperation with the test response module 22 andthe test control module 18 respectively. Bulk transfers will be retriedautomatically, if the data payload is determined to be in error. Forexample, an error condition is the repeated failure of a bulk datatransmission beyond a reasonable limit established by the user via thetest control module 18; another error condition is a data error that wasnot detected by the USB host controller 24.

At S12, the test control module 18 further causes an isochronoustransfer test to be performed. The purpose of the test is to ensure thathigh volume constant-rate data is transmitted properly and accuratelyover the USB port 16. More specifically, the isochronous transfer testis conducted by performing continuous transfers to and from the testdevice 12. The isochronous transfer test first allocates an isochronoustransfer bandwidth allocation from the USB host controller 24. Byallocating bandwidth for this isochronous transfer, the test device 12is guaranteed the requested amount of USB bus bandwidth as part of eachUSB frame. Then, the test device 12 begins sending a maximum amount ofisochronous data in an attempt to determine whether the USB hostcontroller 24 properly handles a device that uses up the entire slice ofUSB frame time given to it. Data is sent using the maximum isochronousdata payload size, which is 1023 bytes. The test is repeated in bothdirections, with both the test control module 18 transmitting data tothe test device 12, and with the test device 12 transmitting data to thetest control module 18.

The success of the isochronous transfers is then verified by the testcontrol module 18 and test response module 22 respectively. The testcontrol module 18 and the test response module 22 verify that theisochronous transfer has occurred at the correct time and that suchtransfer is completed. Isochronous transfers are expected to beperformed by the USB host controller 24 after all non-isochronous datathat is to be sent in a USB frame has been processed, or when onlyenough time remains in the current USB frame to send the allocatedamount of isochronous data. Both the test control module 18 and the testresponse module 22 verify if isochronous transfers are made at theappropriate time.

It should be noted that isochronous transfers are not error-correctedand incorrect data transmission is not considered an error condition.Error conditions, for example, include a failure to begin theisochronous transfer with sufficient time for such transfer to completebefore a USB frame ends, or a failure of the USB host controller 24 tosend or receive all data in the isochronous data packet. This test maybe repeated at various isochronous transfer data payload sizes. Payloadsize is allowed to range from 1 to 1023 bytes according to the USB 1.1specification.

At S12, the test control module 18 causes an interrupt transfer test tobe performed. The purpose of the test is to verify that interrupttransfers are completed at proper intervals. Interrupt transfer is amechanism by which the USB host controller 24 can be directed to performinfrequent transmissions of low-volume data with a guaranteed intervalbetween transmissions. Interrupt transfers are used to transmit 1, 2, 4,8, 16, 32 or 64 bytes of data at a time. Such transfers are suited forapplications such as USB keyboards, where the USB keyboard needs to bepolled frequently for new keys that may have been pressed or released.The USB specification allows a USB device to define the frequency atwhich a USB interrupt transfer is initiated by the USB host controller24. The initiation of this interrupt transfer is maintained by eitherthe USB host controller 24 or the USB device driver, or a combination ofboth.

To test the interrupt transfer initiation feature of the USB hostcontroller 24, the test control module 18 requests varying intervals forthe initiation of the interrupt transfers, and the test device 12monitors and reports the interval at which the interrupt transfers aresent. If the value that is requested from the USB device driver or theUSB host controller 24 does not match the frame interval that isobserved by the test device 12, then an error has occurred. This checkcan either by hardware or O/S-dependent, depending on the operatingsystem and the hardware configuration. The USB specification v.1.1allows the interval between two interrupt transfers to be 1 to 255milliseconds.

During the interrupt transfer test, the test control module 18 firstsends a message to the test response module 22 instructing it how muchinterrupt payload data it should send to the USB host controller 24 whenit receives an interrupt transfer frame. This payload data size can be1, 2, 4, 8, 16, 32 or 64 bytes, according to USB specification v.1.1,and other values may be available in other USB specifications. Then, thetest control module 18 instructs the USB host controller 24 to startinterrupt transfers at specific intervals. The test response module 22responds to these interrupt transfers by sending a response that usesthe selected data payload size. The data that is sent in the datapayload contains a sequence number that is maintained by the testresponse module 22. Based on the received interrupt data payloads, thetest control module 18 then verifies that all interrupt transfers werecompleted at proper intervals in the proper sequence. Possible errorconditions are failure to receive interrupt transfer data, missinginterrupt transfer data, incorrect sequence for interrupt transfer data,incorrect interval between interrupt transfers and corrupted interrupttransfer data.

At S14, the test control module 18 causes a low-speed device detect testto be performed. The purpose of the test is to ensure that a low-speeddevice can be detected over the USB port 16. USB devices can eitheroperate at full speed, 12 megabits per second, or low speed, around1-1.5 megabits per second. However, it is contemplated that USB devicescan also operate at speeds other than full and low. The full and lowspeed detect test is accomplished by including a programmable resistorin the test device 12 that can be programmed to be a pull-up on eitherthe D+ or D− signal wire. For a low speed test, the programmableresistor is changed from a pull-up resistor on the D+ signal wire to apull-up on the D− signal wire. The test control module 18 thendetermines if the test device 12 appears to the USB host controller 24as a low-speed device. Possible error conditions include failure of theUSB host controller 24 to detect the signaling for a low-speed device.In the future, there may be additional modes that can be tested.

At S15, once all the tests have been performed in accordance with theprior steps, the test control module 18 reviews all the test results andstatistics and then determines whether all the tests have been passed.If so, the testing is complete and a user is informed that the USB port16 is functioning properly. In a specific embodiment, a “no errors”light can be lit to provide visual indication that the USB port 16 isfunctioning properly. Optionally, a bell may sound or a message may besent to the user.

A S16, if errors are detected, the errors are reported to the user. In aspecific embodiment, errors can be sent in a file, displayed on ascreen, or an error-detected light may be illuminated. Additionally, astatistical analysis of all tests done may be outputted to the userregardless of whether there were errors or not.

In another exemplary embodiment, as described above, the test device 12includes a port capable of receiving a USB cable. In an alternativetesting configuration, the test device 12 is used to test a USB cable.The test device 12 is connected via the port to a previously determinedworking USB cable which, in turn, is connected to the USB port 16. TheUSB port 16 is then tested using the series of tests as described above.Once it is confirmed that the USB port 16 is functioning properly, thepreviously determined working USB cable is replaced with a USB cablewhich is to be tested. The test control module 18 then initiates theseries of tests as described above. If any of the tests fails, then itis an indication that the tested USB cable is not functioning properly.

The above description is illustrative and not restrictive. Manyvariations of the invention will become apparent to those of skill inthe art upon review of this disclosure. The scope of the inventionshould, therefore, be determined not with reference to the abovedescription but instead should be determined with reference to theappended claims along with their scope of equivalents.

1. A system for testing a host computing device having a universalserial bus host controller and a serial bus port, comprising: a testcontrol module residing on said host computing device, the test controlmodule comprising software to enable at least one of the universalserial bus host controller and the serial bus port; and a test devicecoupled to said universal serial bus host controller via said universalserial bus port; wherein said test control module communicates with saidtest device in order to perform a series of tests on said universalserial bus host controller and said universal serial bus port, whereinthe series of tests includes at least one test selected from the group:a voltage level test, a full-speed device detect test, a frame timingcheck, a bus signal and power voltage test, a bulk transfer test, anisochronous transfer test, an interrupt transfer test, and a low-speeddevice detect test.
 2. The system according to claim 1, wherein saidseries of tests includes a voltage level test.
 3. The system accordingto claim 1, wherein said series of tests include a full-speed devicedetect test.
 4. The system according to claim 1, wherein said series oftests includes a frame timing check.
 5. The system according to claim 1,wherein said series of tests includes a bus signal and power voltagetest.
 6. The system according to claim 1, wherein said series of testsincludes a bulk transfer test.
 7. The system according to claim 1,wherein said series of tests includes an isochronous transfer test. 8.The system according to claim 1, wherein said series of tests includesan interrupt transfer test.
 9. The system according to claim 3, whereinsaid series of tests includes a low-speed device detect test.
 10. Asystem for testing a host computing device having a universal serial busport, comprising: a test device coupled to said universal serial busport, said test device further includes a device controller and a testresponse module; a test control module configured to communicate withsaid test response module in order to conduct a series of tests to testsaid universal serial bus port, the test control module furtherconfigured to install one or more drivers to enable at least one of auniversal serial bus host controller and the universal serial bus port;wherein said series of tests includes a voltage level test, a frametiming check, and a bus signal and power voltage test.
 11. The systemaccording to claim 10, wherein said series of tests further includes afull-speed device detect test, a bulk transfer test, an isochronoustransfer test, an interrupt transfer test, and a low-speed device detecttest.
 12. The system according to claim 10, wherein said test responsemodule in response to instructions received from said test controlmodule causes said device controller to provide information inaccordance with a specific test; and wherein said information isforwarded to said test control module to allow said test control moduleto determine whether said universal serial bus port is functioningproperly.
 13. A method for testing a host computing device having auniversal serial bus port and a universal serial bus cable using a testdevice and a test control module, comprising: enabling the universalserial bus port using software from a source other than an operatingsystem running on the host computing device; connecting said test deviceto said universal serial bus port; initializing said test device;causing said test device to provide information for a series of tests inresponse to instructions received from said test control module, whereinthe series of tests includes at least one test selected from the group:a voltage level test, a full-speed device detect test, a frame timingcheck, a bus signal and power voltage test, a bulk transfer test, anisochronous transfer test, an interrupt transfer test, and a low-speeddevice detect test; communicating said information to said test controlmodule; and causing said test control module to analyze said informationto determine whether said universal serial bus port is functioningproperly.
 14. The method of claim 13, wherein said series of testsincludes a voltage level test, a frame timing check, and a bus signaland power voltage test.
 15. The method of claim 14, wherein said seriesof tests further includes a full-speed device detect test, a bulktransfer test, an isochronous transfer test, an interrupt transfer test,and a low-speed device detect test.
 16. The method of claim 13, whereininitializing said test device comprises configuring said test deviceaccording to a USB protocol.
 17. The method of claim 13, whereincommunicating said information to said test control module comprises:sending a request for said information in a control packet to said testdevice; and sending said information in a response packet from said testdevice to said test control module.
 18. The method of claim 13, furthercomprising: upon confirming that said universal serial bus port isfunctioning properly, connecting said a universal serial bus cablebetween said test device and said universal serial bus port; causingsaid test device to provide information for said series of tests inresponse to instructions received from said test control module;communicating said information to said test control module; and causingsaid test control module to analyze said information to determinewhether said universal serial bus cable is functioning properly.
 19. Thesystem of claim 1, wherein the test control module is configured to beexecuted in an operating system that does not support a USB protocol.20. The system of claim 19, wherein the test control module isconfigured to be executed in DOS.
 21. The system of claim 10, whereinthe test control module is configured to be executed in an operatingsystem that does not support a USB protocol.
 22. The system of claim 21,wherein the test control module is configured to be executed in DOS. 23.A computer program product for testing at least one of a universalserial bus host controller and a universal serial bus port of a hostcomputing device, the computer program product comprising acomputer-readable medium containing computer program code for performingthe steps: enabling at least one of the universal serial bus port andthe universal serial bus controller of the host computing device usingsoftware from a source other than an operating system running on thehost computing device; communicating information with a test devicecoupled to the universal serial bus host controller via the universalserial bus port; and testing at least one of the universal serial busport and the universal serial bus controller of the host computingdevice by analyzing the information communicated with the test device.24. The computer program product of claim 23, wherein the computerprogram product is configured to be executed in an operating system thatdoes not support a USB protocol.
 25. The computer program product ofclaim 24, wherein the computer program product is configured to beexecuted in DOS.
 26. A system for testing a host computing device havinga universal serial bus host controller and a serial bus port,comprising: a test control module residing on the host computing device;and a test device coupled to the universal serial bus host controllervia the universal serial bus port; wherein the test control modulecommunicates with the test device in order to perform a series of testson the universal serial bus host controller and the universal serial busport, and wherein the test device is configured to be directly connectedwithout a cable to the universal serial bus port during the tests.
 27. Amethod for testing a host computing device having a universal serial busport using a test device and a test control module, comprising:connecting the test device directly to the universal serial bus portwithout a cable; initializing the test device; causing the test deviceto provide information for a series of tests in response to instructionsreceived from the test control module; communicating the information tothe test control module; and causing the test control module to analyzethe information to determine whether the universal serial bus port isfunctioning properly.